[Cloud Security] Removing license gate keeping and displaying the table when there are findings#190285
Conversation
…led but there are findings
|
/ci |
|
/ci |
|
Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security) |
| </div> | ||
| ); | ||
|
|
||
| const useEnsureDefaultNamespace = ({ |
There was a problem hiding this comment.
here to line 661 did not change, i just moved it to the top because this file is hard enough to read, having utility functions both at the top of the file and at its bottom was making it really confusing
|
|
||
| const SUBSCRIPTION_QUERY_KEY = 'csp_subscription_query_key'; | ||
|
|
||
| export const useSubscriptionStatus = () => { |
There was a problem hiding this comment.
nit: if we rename the only hook, should we also rename the file? not like we strictly follow one hool per file policy, so just a nit
| const location = useLocation(); | ||
| const dataViewQuery = useDataView(CDR_MISCONFIGURATIONS_DATA_VIEW_ID_PREFIX); | ||
| const { data: getSetupStatus, isLoading: getSetupStatusIsLoading } = useCspSetupStatusApi(); | ||
| const getLatestFindings = useLatestFindings({ sort: [['asc']], enabled: true, pageSize: 1 }); |
There was a problem hiding this comment.
what about making this a part of the /status API? I think we will need this check in many places, one I know about is the Contextual Flyout for the empty. I think it's better to have a well-defined API for that rather than doing it in every place again and again
There was a problem hiding this comment.
plus there is a check for muted/unmuted findings integrated in the useLatestFindings and I'm not sure if we want it here. If I'm not missing smth, if there are findings but all muted, this page would show the "install CSPM integration" block, while the integration is installed. Is this correct?
For me, this is another pro of having this as a part of the status API. there we can encapsulate pure statuses, without the risk of the logic being affected by the changes in the useLatestFindings hook
There was a problem hiding this comment.
I was having the same contemplation regarding the muted rules. One thing to keep in mind is that we only support rule muting for native findings. Meaning CDR rules will never have filtered out findings, at least on paper.
Meaning that using the current useLatestFindings is basically keeping the same logic that we always had without changing any flow, which is the same as you mentioned, all native findings muted -> integration installation prompt. Ideally we should have some "all findings are muted" prompt or something, but we don't have that yet.
I was also having the same contemplation regarding the status API tbh, ended up with what you see cause I figured I want to use exactly what the table is using so there's no chance of the API saying "have findings" while the table is like "nope". or vise versa somehow. I can't think of something that can cause that right now, but it might come up in the future and it's just an additional thing to keep in mind. I'm ok with changing it to use an API, lmk if you still think its better after i explained my reasoning
There was a problem hiding this comment.
I am in favor of defining a clear status API and then combining them in the react components according to the use case. If we need to reuse some logic between the data grid and the page itself, we can always come up with an abstraction for it. Right now there is an implicit coupling between different pages, plus there are side effects like muting logic which might not be desirable, even if for now we are ok with it
| { | ||
| range: { | ||
| '@timestamp': { | ||
| gte: `now-${LATEST_FINDINGS_RETENTION_POLICY}`, |
There was a problem hiding this comment.
should we also include the retention policy as a function parameter? so the function will be truly generic to other use cases such as vulnerabilities.
opauloh
left a comment
There was a problem hiding this comment.
just a comment, LGTM overall!
| hasFindings || | ||
| const hasFindings = | ||
| hasMisconfigurationsFindings || | ||
| getSetupStatus?.kspm.status === 'indexed' || |
There was a problem hiding this comment.
nit: I think getSetupStatus?.kspm.status === 'indexed' || getSetupStatus?.cspm.status === 'indexed' check is not needed anymore, I can't think of a scenario when there are no documents in the CDR index pattern, but either kspm or cspm is indexed
| installedPackagePoliciesVulnMgmt, | ||
| installedPolicyTemplates, | ||
| ] = await Promise.all([ | ||
| checkIndexHasFindings(esClient, CDR_MISCONFIGURATIONS_INDEX_PATTERN, logger), |
There was a problem hiding this comment.
let's add an API integration test for the new piece of information.
maxcold
left a comment
There was a problem hiding this comment.
Looks good, also tested on a security serverless project.
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @JordanSh |
Summary
Findings are displayed without CSP integration installed
Screen.Recording.2024-08-12.at.15.54.18.mov
License check moved to integration page
Screen.Recording.2024-08-12.at.15.56.19.mov
Skips license block on serverless: